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ABSTRACT 


AUTHOR:  LTC  (P)  Jerome  F.  Payne,  IN/AC  (with  Fellowship  at  University  of 

Texas) 

TITLE:  Recapitalization  of  Tactical  Computer  Automation  Systems 

FORMAT:  Fellowship  Research  Project 

DATE:  1  April  2002  PAGES:  30  CLASSIFICATION:  Unclassified 

In  early  1990  the  Army  made  a  conscience  decision  to  leverage  the 
development  of  “Commercial-O/f-The-She/f  ”  (COTS)  computer  hardware  and 
related  components  for  integration  into  military  applications.  This  decision  was 
driven  primarily  by  the  growing  cost  of  automation  hardware  developed  to 
Military-Specifications  (Standards)  which  were  often  seen  as  unjustifiable,  usually 
exceeding  the  required  operating  threshold  and  far  too  costly  to  produce.  Since 
that  time,  the  Army  has  spent  approximately  $1 B+  fielding  tactical  computer  and 
automation  hardware  designed  to  enhance  the  field  commander’s  situational 
awareness  of  the  battlefield.  Given  today’s  budget  constraints,  the  Army  will  not 
be  able  to  rely  on  a  continual  flow  of  funds  to  reprocure  hardware  as  the  current 
generation  of  systems  fail  to  keep  up  with  the  growing  demands  of  software.  In 
this  light,  the  Army  must  begin  to  pursue  alternatives  toward  extending  the  useful 
life  of  automation  hardware  already  in  the  field. 

Due  to  the  ever-growing  resource  requirements  needed  to  efficiently  run 
multi-layered  system  software  such  as  Unix  (Operating  System  Software),  the 
Army  Battle  Command  System  (ABCS)  software  suite  and  functional  application 
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software  (e.g.  AFATDS,  ASAS,  MCS,  etc)  the  Army  is  beginning  to  see 
limitations  in  the  efficient  operation  of  tactical  computer  hardware  systems, 
particularly  those  systems  fielded  earliest.  Most  computer  hardware  currently 
fielded  may  not  be  able  to  continue  to  run  efficiently  in  view  of  current  software 
growth  trends  and  the  complexity  related  to  increasing  performance  of  fielded 
legacy  systems.  If  left  unchecked,  this  situation  could  have  significant  impact  on 
the  Army’s  transformation  effort  and  timeline  for  fielding  a  fully  digitized  combat 
organization  with  a  seamless  C4I  capability  and  unmatched  lethality, 

The  intent  of  this  paper  is  to  lay  out  how  the  Army  got  to  where  it  is  today 
and  hopefully  delineate  actions,  which  need  to  be  taken  now  and  in  the  future  to 
keep  this  important  effort  on  track.  Please  note  that  for  the  purpose  of 
narrowing  the  scope  of  this  project  the  author  has  focused  on  only  the  primary 
ABCS  software  applications  which  would  include:  Maneuver  Control  System 
(MCS),  All  Source  Analysis  System  (ASAS),  Advanced  Field  Artillery  Tactical 
Data  System  (AFATDS),  Forward  Area  Air  Defense  C2I  (FAAD  C2I)  Combat 
Service  Support  Control  System  (CSSCS),  Aviation  Mission  Planning  System 
(AMPS),  Digital  Topographic  Support  System  (DTSS),  and  the  Army  Battle 
Command  System  (ABCS) . 
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Recapitalization  of  Tactical  Computer  Automation  Systems 


“The  Department  of  Defense  continues  to  face  a  limited  investment  budget 
constrained  by  a  relatively  stable  top-line  budget,  and  squeezed  by  increased 
operations  and  support  cost  for  aging  weapons  systems.” 1 


The  current  pace  of  “Commercial-Off-The-Shelf  (COTS)  computer 
component  migration  is  adversely  affecting  the  projected  useful  life  of  the  Army’s 
new  ruggedized  tactical  computer  systems  -  accelerating  planned  rebuy/refresh 
funding  points  for  Product/Program  Managers  and  making  it  difficult  to  accurately 
work  to  develop  cost  effective  recapitalization  strategies  for  their  fielded  systems. 

The  purpose  of  this  paper  is  two  fold.  First,  it’s  to  analyze  and  discuss  the 
Army’s  implementation  of  Secretary  of  Defense  William  Perry’s  1994  directive  to 
integrate  and  leverage  commercial-off-the-shelf  components  in  the  design  and 
production  of  systems  developed  and  procured  by  the  Department  of  Defense 
(DoD).  In  this  part  of  the  discussion,  the  author  intends  to  highlight  the 
advantages  and  disadvantages  of  COTS  components  as  they  are  integrated  into 
today’s  tactical  computers  and  automation  hardware  systems.  The  second 
purpose  is  to  identify  a  number  of  recommendations  (some  obvious  -  some  not 
so  obvious)  as  to  what  can  and  should  be  done  by  way  of  recapitalization 
activities  to  get  the  most  out  of  our  current  materiel  investment.  Whether  referring 
to  the  activity  as:  modernization,  recapitalization,  rebuild,  rebuy,  or  refurbish,  the 
real  question  on  the  table  from  the  Army  leadership  is:  “What  can  be  and  is  being 
done  to  extend  the  useful  life  of  its  $1B+  investment  in  tactical  automated 


systems  supporting  digitization  and  ultimately  the  Army’s  Transformation 
Program?” 

In  their  book,  War  and  Anti-War.  Alvin  and  Heidi  Toffler  describe  three 
waves  of  warfare.  The  first  wave  was  agrarian  warfare  (Pre-1864),  the  second 
wave  was  industrial  warfare  (1864-1989),  and  the  third  wave  is  information 
warfare.  Operation  Just  Cause  and  Desert  Storm  represent  the  first  campaigns 
of  this  third  wave. 2 

Since  the  end  of  Desert  Storm,  the  Army  and  other  DoD  agencies  (i.e. 
Marines,  National  Guard,  Army  Reserves,  etc.)  have  procured  well  in  excess  of 
10,000  computers,  the  majority  of  which  were  ruggedized  and  designed  for  use 
in  the  types  of  harsh  environmental  settings  the  user  may  be  deployed  to  fight. 
This  number  reflects  only  those  tactical  computers  built  and  delivered  by  way  of 
the  Army’s  Common  Hardware  Program,  and  does  not  reflect  computers  which 
may  have  been  procured  through  a  myriad  of  other  contract  vehicles.  Therefore, 
the  total  number  of  tactical  computers  in  operation  today  may  well  be  in  numbers 
of  an  even  greater  magnitude.  The  important  point  here  is  to  demonstrate  the 
immense  proliferation  of  tactical  automation  systems  used  by  the  Army  and  sister 
services  since  it  began  in  the  late  1980s  and  early  1990s,  as  well  as,  the  need 
for  a  plan  to  address  recapitalization  of  this  significant  investment. 

Background 

In  1994,  the  Secretary  of  Defense,  Dr.  William  Perry  implemented  an 
initiative  that  essentially  moved  the  services  toward  a  COTS  approach  to  materiel 


? 


development.  This  initiative,  an  aspect  of  the  Acquisition  Reform  Act,  was 
promoted  by  DoD  in  order  to  contain  military  costs  by  eliminating  the  design  of 
customized  application-specific  systems.  Subsequently,  the  initiative  forced  the 
services  to  reduce  their  traditional  reliance  on  military  specifications  for  materiel 
acquisition  and  to  seek  out  COTS  solutions  whenever  and  wherever  applicable. 
Use  of  commercial  standards  and  specifications  were  to  become  the  norm,  and 
subsequently  the  services  were  required  to  request  special  waivers  for  the  use  of 
Mil-Spec  in  procurement  of  items  in  the  years  that  followed.  The  impetus  for  this 
initiative  was  clear.  It  was  in  DoD’s  best  interest  to  leverage  research, 
development  and  acquisition  (RD&A)  investments  in  the  commercial  sector,  and 
in  so  doing,  free  up  declining  defense  dollars  for  other  pressing  requirements 
such  as  combat  system  modernization,  training,  and  procurement. 

Since  the  end  of  the  Cold  War,  U.S.  defense  spending  has  dropped  40% 
of  what  it  was  at  its  peak,  and  DoD’s  procurement  budget  is  down  by  65%.3 
Subsequently,  military  influence  in  the  electronics  and  semiconductor  market  has 
been  reduced  proportionately.  In  the  1970s,  the  military  purchased  and 
controlled  more  than  30%  of  the  electronics  sector.  By  the  mid-1980s,  the 
military’s  share  had  fallen  to  approximately  7%.  Today,  DoD  purchases  less  than 
1%  of  the  industry’s  total  semiconductor  output 4  When  the  military  lost  its 
market  share,  it  lost  its  influence.  The  bottom  line  is  that  today  COTS 
development  is  driven  by  consumer  need  and  commercial  trends,  and  DoD  is 
primarily  a  spectator,  forced  to  leverage  commercial  technology  developments 
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rather  than  direct  them.  This  is  a  reality  that  apparently  the  Army  and  DoD  user 
community  has  yet  to  fully  accept! 

What  does  that  mean  to  the  Army?  On  one  hand  military  system 
developers  love  the  low  cost,  cutting  edge  technology  provided  by  way  of  COTS 
materiel  integration;  however,  the  major  downside  of  COTS  is  the  short 
obsolescence  cycle  and  lack  of  corporate  incentive  to  ensure  the  next  generation 
component  seamlessly  integrates  into  the  old  system.  Technical  experience  in 
this  area  is  that  seldom,  if  ever,  does  the  next  generation  component  fit  into  the 
previous  system,  share  the  same  footprint  or  works  easily  with  earlier  external 
system  interfaces.  Those  components  that  do,  usually  require  significant 
program  funding  to  rehost  system  software,  develop  new  drivers,  update 
firmware,  or  customize  circuitry  to  accommodate  next  generation  voltage 
architectures  (i.e.  the  5-v  transition  to  3.3-v  or  1.8-v,  etc.).  In  view  of  these 
challenges,  how  will  the  Army  maintain  a  system  for  10  to  15  years  when  the 
integrated  commercial  electronics  will  be  obsolete  in  18-24  months  and,  for  the 
most  part,  no  longer  available? 

Digitization  and  Army  Transformation 

In  order  to  understand  the  overall  complexity  of  the  COTS  issue  as  it 
relates  to  fielding  schedules  and  the  Army’s  “unit  set  fielding”  (USF)  initiative  it  is 
important  to  understand  where  we  were  as  an  Army  and  where  we  are  going  with 
transformation.  With  the  end  of  the  Cold  War,  the  Army  was  forced  to  take  a 
good  look  at  itself  and  its  relevancy  with  regard  to  the  type  of  operations  it  would 
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be  called  upon  to  respond  to  in  the  future.  It  was  clear  that  as  the  force  was 
reduced  in  size,  joint  operations  would  become  far  more  important.  Operations 
Other  Than  War  (OOTW)  would  become  the  norm,  warfare  would  no  longer  be 
fought  on  a  linear  battlefield.  Network  Centric  warfare  was  the  future  and 
success  hinged  on  the  ability  to  see  and  influence  the  battlefield  three 
dimensionally  and  at  greater  distances  with  fewer  forces  than  ever  before. 
Seamless  integration  of  Command,  Control,  Communication,  and  Computer 
Intelligence  (C4I)  systems  was  critical  to  this  new  method  of  warfare. 
Subsequently,  the  Army’s  challenge  was  to  change  an  acquisition  process  that 
at  one  time  supported  numerous  “stovepipe  information  systems”  (i.e.  MCS, 
AFATDS,  CSSCS,  etc)  and  meld  it  into  a  functional,  interoperational 
communications  architecture.  What  followed  was  a  series  of  Advanced 
Warfighting  Experiments  (AWE)  intended  to  identify  “high  payoff’  technologies 
and  shake  out  network  C4I  shortcomings.  From  the  warfighters  perspective, 
their  mission  was  clear  —  learn  how  to  use  and  employ  these  new  information 
technology  (IT)  systems  to  increase  the  unit’s  lethality  and  protection  of  our 
forces.  But  for  the  Program  Managers  (PM)  on  the  materiel  acquisition  side, 
acquisition  transformation  introduced  a  whole  new  set  of  challenges,  many  of 
which  they  continue  to  wrestle  with  today.  First,  their  programs  all  have 
different  acquisition  strategies  and  fielding  schedules.  Second,  each  program  is 
funded  separately,  independent  of  the  maturity  level  of  those  C4I  programs  with 
which  it  may  interoperate.  Third,  each  program  is  under  the  control  of  a  different 
Training  and  Doctrine  Command  (TRADOC)  training  center  established  to  meet 
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different  requirements  as  laid  out  in  an  approved  Operational  Requirements 
Document  (ORD).  To  further  exacerbate  the  situation,  many  of  the  system 
ORDs  have  different  environmental  performance  requirements  in  spite  of  the  fact 
that  these  systems  will,  in  most  cases,  all  have  to  perform  side  by  side  in  the 
same  environment. 

In  early  1999,  TRADOC  began  to  work  toward  producing  a  Capstone 
Requirements  Document  (CRD).  Its  purpose  was  to  establish  a  baseline  of 
minimum  performance  requirements  common  to  all  systems  operating  as  a 
primary  Battle  Field  Area  (BFA)  software  application  under  the  Army  Battle 
Command  System  (ABCS)  umbrella.  Currently  that  document,  the  ABCS  CRD 
(dated  31  August  2000),  serves  to  guide  user  requirements  and  bring 
consistency  with  regard  to  environmental  performance  parameters  and  system 
capabilities. 

What  exactly  is  COTS? 

COTS  information  technology  refers  to  a  wide  range  of  available  hardware  and 
software  produced  by  industry  for  use  in  commercial  markets.  It  may  refer  to 
board  level  components  built  into  a  product  or  system,  or  it  may  refer  to  a 
complete  end  product  or  system.  Since  COTS  is  produced  by  the  commercial 
sector,  its  development  and  marketing  reflect  typical  commercial  priorities  such 
as  cost  competitiveness,  time  to  market,  and  the  ability  to  capture  market  share 
(percent  of  the  commercial  market  the  corporation/company  organization  wants 
to  own  and  control).5 
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When  the  Army  made  the  decision  to  use  COTS  in  a  tactical  environment, 
no  one  knew  just  what  the  implications  of  COTS  integration  might  be. 
Subsequently,  the  term  COTS  means  different  things  to  different  customers.  If 
you  ask  anyone  in  the  commercial  sector  to  define  COTS,  their  answer  will  be 
something  you  can  buy  and  use  “as  is”  directly  from  the  vendor.  DoD  has  a 
somewhat  different  definition  however.  To  DoD,  COTS  means  that  an  item  is 
manufactured  using  best  commercial  practices.  The  spirit  of  COTS  is  to  use 
products,  technologies  and  services  that  are  readily  available  from  industry, 
without  a  government  or  military  contractor  having  to  develop  them  from 
scratch. 6 

The  problem  is  that  there  are  currently  few  if  any  commercial  contractors 
who  manufacture  computer  or  automation  products  ,  which  are  sold  on  the 
consumer  market  and  can  meet  Army  user  requirements  “off  the  shelf  or  “out  of 
the  box,“  as  defined  in  an  approved  Operational  Requirements  Documents 
(ORDs)  without,  in  some  cases,  significant  modification.  Furthermore,  the 
Operational  Test  community  has  shown  tremendous  reluctance  in  granting  any 
program  relief  or  negotiating  a  compromise  in  key  performance  parameters 
(KPPs)  as  stated  in  the  user’s  ORD,  in  spite  of  how  unrealistic  some  KPPs  may 
be  when  evaluated  in  terms  of  the  technical  maturity  of  similar  systems  in  the 
commercial  market.  Often  this  dilemma  results  in  a  good  program  dying  a  slow 
but  certain  death  because  the  old  paradigm  of  tailoring  specific  military 
development  efforts  and  high  expectations  from  the  user  community  cannot  be 
met  with  a  pure  COTS  solution.  If  they  could,  the  cost  to  modify  or  adapt  a 
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COTS  technology  may  prove  to  be  cost  prohibitive.  In  the  end,  the  materiel 
developer  could  have  provided  the  user  a  leap  ahead  capability  and  by 
integrating  COTS,  keep  the  cost  within  available  program  funding  parameters. 
Instead,  the  user  loses  out  because  COTS  “as  is”  cannot  meet  the  KPP,  and 
developing  an  objective  system  which  meets  all  the  users  requirements  is  cost 
prohibitive. 

The  use  of  COTS  requires  a  number  of  trade-offs  based  upon  the 
environment  in  which  it  will  be  used.  The  Army  Materiel  Command  (AMC), 
Communications  Electronics  Command  (CECOM),  and  subordinates  Program 
Executive  Offices  (PEO)  are  aggressively  implementing  Secretary  Perry’s  vision 
of  COTS  integration  using  a  strategy  referred  to  as  “  Adopt,  Adapt,  and 
Develop.” 7  Each  approach  is  explored  based  upon  the  specific  requirement, 
implementation  cost,  and  development  schedule  of  the  product. 

The  strategy  of  adopting  COTS  is  certainly  the  most  preferred  from  both  a 
cost  and  schedule  perspective;  however,  the  majority  of  all  systems  required  to 
operate  in  a  field  environment  must,  as  stated  earlier,  undergo  some  degree  of 
modification  or  adaptation  to  meet  functionality  and  reliability  requirements. 
Therefore,  the  majority  of  all  computer  hardware  procured  and  provided  to 
combat  units  to  date  has  been  adapted  COTS  -  components  modified  or 
ruggedized  to  meet  clearly  defined  performance  parameters  and  packaged  to 
meet  a  specific  integration  footprint.  The  term  adapted  refers  to  the  fact  that  at 
the  board  level,  components  in  these  tactical  computers  are  pure  COTS. 
However,  in  order  to  increase  system  reliability,  robustness  and  tolerance  to  a  full 
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spectrum  of  environmental  stresses,  a  number  of  manufacturing  modifications 
must  take  place  which  may  include  but  would  not  be  limited  to  the  following: 
exterior  casings  may  be  specially  designed  to  absorb  impact  shock  from 
dropping  the  item;  specially  designed  removable  hard  disk  drive  encasements 
are  developed  to  reduce  the  impact  of  vibration  while  the  system  is  in  use  and 
the  combat  platform  is  on  the  move  ( a  requirement  placed  in  many  system 
ORDs  and  the  ABCS  CRD);  Electromagnetic  Interference  (EMI)  gaskets  and 
filtering  are  integrated  throughout  the  complete  system;  printed  circuit  boards 
are  stiffened  (reinforced);  and  special  mounting  arrangements  are  developed  to 
protect  high  risk  circuitry.  Without  these  modifications  few,  if  any  commercial 
grade  computers  would  survive  the  demands  placed  on  them  in  a  fully  tactical 
environment.  This  was  evident  in  the  Task  Force  XXI  Advanced  Warfighting 
Exercise  conducted  at  the  National  Training  Center  at  Fort  Irwin  in  1997.  Most 
computers,  unless  modified,  cannot  meet  and  perform  properly  in  the  low  and 
high-end  temperature  ranges,  vibration,  and  dust  or  moisture  environments 
required  by  most  users  ORDs.  Commercial  computers  are  not  designed  to  meet 
EMI  requirements.  This  is  critical  in  avoiding  co-site  interference  problems 
created  by  placement  of  an  automation  system  near  or  adjacent  to  other 
operational  data  transmission  devices  (i.e.  SINGARS,  etc).  Commercial 
computers  and  automation  systems  are  also  not  designed  to  survive  “High 
Altitude  Electromagnetic  Pulsing”  (HEMP).  This  is  an  electronic  enemy 
countermeasure  designed  to  destroy  operational  data  systems  such  as  the 


tactical  computer,  using  a  directed  high-energy  pulse  emitted  from  aircraft  or 
missiles  flying  over  the  designated  target  area. 

The  point  is  that  COTS  implementation  should  not  be  strictly  interpreted  to 
have  the  military  user  believe  these  systems  can  meet  the  demands  of  combat 
and  network-centric  warfare  with  computers  purchased  directly  from  the  civilian 
commercial  market  without  being  granted  dramatic  relief  from  system 
performance  and  reliability  requirements  as  established  by  the  user  community. 

As  one  might  expect,  ruggedizing  commercial  class  automation  systems 
and  computers  is  an  expensive  endeavor  even  when  it’s  leveraged  by  a  large 
(relative  to  Army  procurement)  quantity  buy.  A  complete  Common  Hardware 
System  (CHS)  operator’s  (MCS,  CSSS,  ASAS,  etc.)  station  with  ruggedized 
computer,  flat  panel  display,  keyboard,  and  software  costs  approximately  $25- 
30K  each.  Bear  in  mind  that  these  systems  are  contractor  supported  by  way  of 
total  system  warranties.  (More  on  the  CHS  system  warranty  is  addressed  later  in 
this  paper). 

When  Mr.  Perry  announced  his  COTS  and  acquisition  reform  initiatives  in 
1994,  commercial  technology  was  turning  over  every  five  to  seven  years.  Today 
that  rate  of  turnover  is  occurring  approximately  every  18  months.  New 
microprocessors  are  entering  the  commercial  market  every  six  months,  and  next 
generation  memory  families  every  six  to  nine  months.8  Given  this  scenario,  the 
maintenance  cost  can  be  staggering  when  you  consider  that  the  current  defense 
budget  is  forcing  the  services  to  get  longer  and  longer  service  life  from  their 
systems.  In  the  case  of  CHS  and  ABCS  systems,  the  contractor  currently  carries 
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this  maintenance  burden  until  support  ends  between  2005  and  2007  (Note —  All 
hardware  procured  prior  to  2001  will  be  supported  through  2005,  all  subsequent 
procurement  is  warranted  through  2007)  but  that  only  addresses  the 
maintenance  of  the  system  not  the  upgrade  (recapitalization  requirements).  PM’s 
are  currently  responsible  for  ensuring  they  have  adequate  funds  fenced  in  the 
POM  to  support  their  out-year  recapitalization  strategies.  It  is  necessary  to 
understand  that  the  strategies  may  vary  from  PM  to  PM  based  on  a  number  of 
factors. 

Meeting  Materiel  Requirements  with  COTS 

From  the  beginning  the  Army  recognized  a  need  for  C4I  interoperability, 
both  “intra”  and  “inter”  service.  At  the  same  time  the  Army  knew  it  could  no 
longer  afford  to  invest  significant  funds  into  developing  stovepipe  systems  to 
meet  each  individual  user’s  military  system  specifications.  Mandates  for  COTS 
integration,  consideration  of  Cost  as  an  Independent  Variable  (CAIV),  and 
contract  transition  to  the  use  of  Best  Business  Practices  laid  the  foundation  for 
what  was  to  become  the  Common  Hardware  Software  (CHS)  Program. 

CHS  was  a  significant  transition  from  the  old  way  the  Army  was  doing 
business  in  the  computer  and  automated  systems  arena.  The  CHS  program  was 
established  to  increase  Army  Command  and  Control  (C2)  interoperability  and 
decrease  the  cost  of  acquiring  C2  systems.  CHS  is  a  contract  vehicle  which 
essentially  provides  PMs  and  DoD  agencies  the  ability  to  order  computer 
hardware  from  a  commercial  vendor  (General  Dynamics  -  Communications 
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Systems)  in  one  of  three  categories:  pure  COTS  (Version  1),  ruggedized  COTS 
(Version  2),  and  near  mil-spec  (Version  3).  The  CHS  program  was  initiated 
primarily  to  provide  computer  hardware  in  support  of  Army  Battle  Command 
System  (ABCS)  and  its  subsystems  (MCS,  ASAS,  etc).  The  current  CHS-2 
contract  expires  in  2005.  The  Army  is  currently  in  the  process  of  capturing  and 
defining  system  requirements  for  CHS-3,  a  follow-on  contract  scheduled  to  begin 
subsequent  to  the  expiration  of  the  CHS-2  contract  in  the  2005-2006  timeframe. 

Recapitalization:  Upgrade  vs.  Rebuild  vs.  Rebuy  ? 

The  Army’s  Recapitalization  Program  clearly  defines  and  delineates  a 
number  of  possible  approaches  toward  keeping  fielded  systems  refreshed, 
relevant  and  formidable. 

•  Modernization:  The  development  and/or  procurement  of  new  systems 
with  improved  warfighting  capabilities. 

•  Recapitalization:  The  rebuild  and  selected  upgrade  of  currently  fielded 
systems  to  insure  operational  readiness  and  a  zero-time/zero-mile  system. 

-  Rebuild:  Restores  a  system  to  like  new  condition;  inserts  new 
technology  to  improve  reliability  and  maintainability. 

-  Upgrade:  Rebuilds  a  systems  and  adds  warfighting  capability 
improvements  to  address  capability  shortcomings. 

•  Maintain:  Repair  or  replacement  of  end-items,  parts,  assemblies,  and 
subassemblies  that  wear  or  break.9 
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A  successful  recapitalization  plan  for  Army  automation  and  C4I  systems 
would  have  to  implement  more  than  one  of  the  approaches  cited  above  and  in 
some  cases,  simultaneously. 

Case  Study  in  Recapitalization  (Example) 

The  first  rugged  computers  were  delivered  to  the  4th  Infantry  Division  (4ID) 
in  the  mid-1990.  These  systems  had  75  MHz  processors,  4  GB  hard  drives  and 
256  MB  of  RAM  memory  (which  was  state  of  the  art  at  that  time).  Before  the  4th 
ID  fielding  was  completed,  the  systems  being  shipped  to  Fort  Hood  had  migrated 
to  440  MHz  processors,  36  GB  hard  drives,  and  1  GB  of  RAM  memory.  This  was 
due  to  component  end  of  life  (EOL)  notifications  from  vendors.  Often  times  these 
changes  come  with  very  little  advance  notification.  This  allows  the  vendors  to 
deplete  field  supply  stockage  levels  of  the  components  entering  obsolescence 
prior  to  ramping  up  inventories  of  the  replacement  items.  Remaining  component 
inventories  are  used  to  repair  and  maintain  legacy  systems  currently  in  the  field. 
Prior  to  the  Joint  Contingency  Force  (JCF)  Advanced  Warfighting  Exercise 
(conducted  at  Fort  Polk)  and  the  Division  Capstone  Exercise  (DCX  1-  conducted 
at  Fort  Irwin/NTC),  almost  all  PMs  fielding  systems  to  4ID  had  to  upgrade  all 
fielded  systems  to  the  current  larger  hard  drive  and  RAM  memory  at  a  cost  of 
$3K+  per  box  in  order  for  them  to  run  ABCS  6.x  efficiently. 

Under  the  current  fielding  plan,  the  1st  Cavalry  Division  and  III  Corps  will 
be  receiving  the  same  (or  current)  state  of  the  art  computer  platform  as  4ID  has 
now.  As  we  begin  to  field  tactical  computers  to  remaining  off-site  III  Corps  units 
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(i.e.  Fort  Bliss,  Fort  Bragg,  etc.)  and  the  next  digital  division  or  IBCT  beginning  in 
2003,  these  units  will  (in  all  likelihood)  receive  next  generation  computer  systems 
which  will  support  up  to  two  (dual)  700  MHz  processors,  70+  GB  hard  drives,  and 
2  GB  of  RAM  memory.  The  reason  for  this  ever-increasing  difference  in  system 
performance  is  simply  that  the  commercial  sector  is  being  forced  to  meet 
evolving  consumer  demands  and  higher  expectations.  The  difference  between 
a  company’s  success  and  failure  is  their  time  to  market  window  for  getting  next 
generation  capabilities  into  the  hands  of  the  user.  The  down  side,  particularly  for 
DoD,  is  that  very  shortly  after  the  commercial  sector  releases  its  next  generation 
component  or  system,  it  terminates  production  of  the  previous  generation  (End- 
of-Life).  Even  if  the  Army  could  continue  to  run  software  on  a  low-end  system, 
the  parts  simply  would  not  be  available  to  procure.  Therein  lies  the  problem 
because,  as  it  stands  now,  the  4th  Infantry  Division  (the  Army’s  first  Digital 
Division)  has  little,  if  any  ability,  to  accommodate  growth  in  the  ATCCS  systems  it 
currently  has,  should  the  ABCS  software  package,  Solaris  operating  system 
and/or  application  (MCS,  ASAS,  etc)  software  require  additional  RAM  memory  or 
processor  capability.  The  only  recapitalization  approach  is  to  buy  the  newer 
system. 

In  view  of  the  Army’s  inability  to  control  the  rapid  evolution  of  computer 
components  in  the  commercial  sector,  PMs  and  TRADOC  System  Managers 
(TSMs)  will  have  to  adopt  a  number  of  strategies  to  extend  the  useful  life  of  their 
systems.  This  strategy  will  require  influencing  hardware  development  and  close 
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oversight  of  software  and  its  tendency  to  grow  exponentially  with  each 
subsequent  version  or  release  package. 

With  regard  to  software  oversight,  the  Directorate  of  Information  Systems 
for  C4  (DISC4)  working  closely  with  the  Deputy  Chief  of  Staff  for  Operations 
(DCSOPS),  has  already  taken  a  major  step  in  addressing  this  potential  problem 
by  developing  a  software  blocking  policy.  The  significance  of  this  initiative 
cannot  be  understated.  This  policy  provides  executive  level  oversight  and 
approval  authority  for  migration  of  ABCS  and  all  related  application  software 
release  packages.  Any  new  release  package,  operating  system  or  improvement 
to  ABCS  and  its  sub-components  must  be  thoroughly  tested  at  the  Central 
Technical  Support  Facility  (CTSF),  located  at  Fort  Hood,  for  impact  on  the 
system  and  the  network  as  well  as  insuring  its  stability  before  it  is  released  to 
units  which  have  been  digitized.  Furthermore,  release  of  subsequent  software 
release  packages  will  be  limited  to  18  and  36-month  fielding  cycles,  providing 
greater  stability  within  the  ABCS  architecture,  reducing  operational  impact  and 
providing  units  greater  time  to  train  up  on  the  new  software  prior  to  implementing 
the  transition. 

Recommendations: 

Establish  a  stable  software  baseline.  The  recapitalization  activity  of  tactical 
computer  and  automation  systems  will  be  varied  based  on  a  number  of  factors. 

In  May  2001 ,  the  PM,  for  CHS  commissioned  a  study  to  evaluate  the  most 
probable  weak  link  in  our  current  fielded  tactical  computer  systems.10  The 
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analysis  showed  that  the  processors  (at  that  time  440MHz),  were  in  most  cases 
almost  fully  utilized  at  certain  times  of  operation.  The  1 GB  of  RAM  memory  was 
found  to  be  more  than  adequate  to  support  combat  operations  with  the  current 
software.  That  being  the  case,  units  that  have  already  received  or  will  receive 
those  440MHz  systems,  which  have  been  purchased,  should  represent  the 
baseline  for  software  development.  Future  software  releases  must  be  evaluated 
against  this  hardware  baseline  until  such  time  as  there  is  adequate  funding  to 
initiate  a  modernization  effort  based  on  a  system  rebuy  for  the  first  generation  of 
fielded  systems  as  these  tactical  computers  can  not  be  upgraded  beyond  the 
440MHz  processors  which  are  installed  on  their  motherboards.  The  migration 
beyond  the  440MHz  processor  architecture  requires  a  different  commercial 
motherboard. 

Conduct  trade-off  analysis.  For  systems  yet  to  be  fielded  to  the  remainder 
of  the  First  Digital  Corps  (FDC)  PMs  will  have  tremendous  latitude  for  decisions 
on  how  and  when  to  recapitalize  fielded  systems.  Based  on  information  from 
both  General  Dynamics  -Communication  Systems  and  Sun  Microsystems,  the 
next  generation  of  computer  motherboards  will  be  able  to  support  two  650- 
700MHz  processors,  up  to  2  GB  RAM  memory  and  house  a  73GB  removable 
hard  drive  -  providing  ample  room  for  growth  in  support  of  future  requirements. 
Cost  trade-off  analysis  will  be  crucial  to  determining  the  cost  effectiveness  of 
procuring  a  next  generation  system  or  cannibalizing  the  legacy  systems  and 
incorporating,  where  appropriate,  the  older  components  into  the  new  computer 
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housing  and  motherboard.  As  might  be  expected  this  next  generation  board 
does  not  fit  into  the  exterior  housing  of  the  tactical  computers  currently  fielded. 

Increase  funding  of  SE&I  efforts.  Increase  funding  of  ABCS  system 
engineering  and  integration  efforts  (SE&I).  Although  application  software  (e.g. 
MCS,  ASAS,  etc.)  is  being  developed  to  meet  individual  TRADOC 
school  house/combat  developer  requirements  for  their  respective  user,  the  real 
strength  of  digitization  comes  from  the  synergy  created  by  the  seamless 
integration  and  interoperability  of  ABCS  subsystems  at  the  Army  level.  A  solid 
integration  process  is  key  to  the  success  of  making  ABCS  and  FBCB2  seamless 
entities.  The  only  way  to  insure  that  this  happens  successfully  is  through  a  solid 
SE&I  effort. 

Control  software  growth.  Computer  hardware  and  software  must  be  seen 
as  “Siamese  twins”  in  that  what  affects  one  will  surely  affect  the  other.  This 
cannot  be  emphasized  enough!  Never  lose  sight  of  the  fact  that  the  C4I 
architecture  is  only  as  fast  and  stabile  as  its  weakest  link.  All  software,  present 
and  future,  will  have  to  run  as  efficiently  on  legacy  systems  sent  to  the  field  in 
the  last  3-5  years  as  it  does  on  next  generation  systems  going  out  the  door 
today.  One  of  the  greatest  frustrations  for  those  who  develop  military  oriented 
computer  hardware  today  is  that  PMs  simply  do  not  know  what  the  minimum 
hardware  requirements  are  to  run  the  current  version  of  ABCS  6.x  (or  7  and 
beyond).  Compound  this  by  adding  the  Solaris  7.0  operating  system  (with  plans 
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to  migrate  to  possible  8.0  or  9.0  in  the  next  year  or  so)  then  add  the  BFA 
application  software.  Unlike  the  “minimum  system  requirements”  printed  on  the 
side  of  a  box  of  Windows  98  or  2000,  the  Army  has  yet  to  determine  what  the 
minimum  requirements  are  for  a  using  these  tactical  computers  and  the  myriad  of 
software  bundles  which  form  that  situational  awareness  product  we  refer  to  as 
ABCS.  As  the  Army  and  sister  services  determine  the  software  requirements  for 
this  new  network-centric  architecture,  it  is  imperative  that  the  CTSF  establish 
“metrics”  for  determining  the  minimum  and  optimum  hardware  performance 
requirements  to  efficiently  run  ABCS  and  all  additional  software.  This  will  allow 
PMs  to  know  the  requirements  of  hardware  needed  by  soldiers  in  the  future 
today,  and  to  be  able  to  procure  these  systems  with  adequate  growth  built-in, 
but  at  the  same  time  not  pay  for  performance  far  in  excess  of  what  will 
realistically  be  needed. 

Reduce  hardware-software  interdependencies.  System  application 
software  developers  often  write  their  software  code  with  a  direct  dependency  on 
the  specific  system  on  which  it  is  being  run  (e.g.  Sun  UltraSparc  Hi).  This  should 
be  avoided.  Open-architecture  should  be  the  standard!  There  maybe  a  good 
rationale  for  this  but  it  creates  a  number  of  problems  for  PMs.  First,  any  change 
in  hardware  platforms  or  sub-components  such  as  a  hard  drive  (which  is 
inevitable)  requires  the  contractor  to  modify,  change,  tweak,  or  develop  the 
software  to  make  the  system  continue  to  run  properly.  Not  only  does  this  take 
time  but  it  leads  to  a  second  problem.  Re-porting  software  to  a  new  platform 
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can  be  an  expensive  proposition  if  proper  preparations  and  funding  adjustments 
have  not  been  made  or  planned  in  advance.  Minor  software  development  efforts 
can  cost  in  the  millions  of  dollars  and  often  far  exceed  the  cost  of  procuring  the 
new  hardware  component. 

Give  Program  Managers  “cradle  to  grave”  responsibility  for  their  systems. 
There  has  been  a  great  deal  of  discussion  as  to  whether  replacement  or  upgrade 
responsibility  should  go  to  the  using  unit  once  fielding  has  been  complete.  This 
approach  can  lead  to  significant  problems  and  is  not  recommended. 
Decentralizing  of  recapitalization  requirements  is  the  equivalent  of  herding  cats. 
Every  commander  would  have  to  plan  for  his  or  her  system  upgrades  without 
being  privy  to  or  have  control  of  external  forces  which  might  force  system 
migration  or  maintain  interoperability.  Funds  earmarked  for  upgrades  or  rebuy 
could  easily  be  diverted  to  meet  unanticipated  but  necessary  contingencies.  It 
is  conceivable  that  within  a  short  period  of  time  tactical  data  communication 
among  major  subordinate  commands  could  become  tenuous  at  best. 

Make  the  Central  Technical  Support  Facility  (CTSF)  the  Army’s  single 
point  of  distribution  for  all  ABCS  functional  and  program  specific  application 
software.  This  is  important  because  each  product  requiring  interoperability  with 
ABCS  may  consist  of  a  number  of  software  release  packages  scheduled  for 
release  over  a  period  of  years  (e.g.,  AFATDS  Pkg  9,  Pkg  10,  etc.).  The  CTSF 
has  the  ability  and  charter  to  integrate  these  software  packages,  work  out  the 
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bugs,  coordinate  the  release  schedules  and  analyze  software  and  hardware 
impact  on  the  total  architecture. 

The  Army  and  DoD  must  continue  to  leverage  R&D  investments  in  the 
commercial  sector.  PMs,  defense  contractors  and  the  user  community  must  get 
together  early  in  the  spiral  development  process  to  insure  that  all  parties  have  a 
clear  understanding  of  “threshold”  versus  “objective”  requirements,  how  realistic 
(achievable)  they  are,  and  the  impact  some  requirements  have  on  system  cost. 
This  would  facilitate  the  identification  of  a  system’s  functionality  or  capability 
which,  due  to  its  current  lack  of  technical  maturity,  may  not  be  realistic  to 
integrate  in  the  near-term  but  could  be  met  by  implementing  a  “block 
improvement  program”  approach  in  system  development,  thereby  giving  the  user 
some  leap-ahead  capability  in  the  near-term  and  an  objective  system  consistent 
with  their  full  requirements  in  a  future  block  upgrade  after  the  technology  has 
matured  to  the  point  where  it’s  ready  for  the  user  community. 

Conclusion 

In  just  a  few  short  years,  the  Army  has  made  incredible  strides  toward 
transforming  into  a  truly  lethal,  responsive,  and  relevant  force  of  the  21st  century. 
Network  centric  warfare  is  here  to  stay  and  clearly  the  way  the  Army  will  fight 
most  of  its  adversaries  in  the  future.  The  Army  must  continue  to  exploit  the 
incredible  potential  of  information  dominance  and  refine  those  systems  that  will 
keep  it  the  world’s  preeminent  super  power.  At  the  same  time,  all  of  these 
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cutting-edge  information  systems,  high  speed  C2  networks,  and  lethal  sensor  to 
shooter  links  still  boil  down  to  a  soldier  drawing  a  line  in  the  sand  and  giving  his 
or  her  life,  if  necessary,  for  principles  established  by  this  nation  long  before 
anyone  dreamed  of  war  as  we  know  it  today. 

The  Acquisition  Corps  has  a  tremendous  responsibility  to  develop  systems 
that  first  and  foremost  provide  soldiers  with  an  overpowering  advantage  over 
their  adversaries  and  balance  this  with  solid  business  decisions  that  will  gain  the 
greatest  return  on  invested  defense  dollars  both  near  and  long  term. 
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